FirstSpirit dient der Erstellung vielseitiger und projektspezifischer Inhalte. Mit ContentConnect wurde die Möglichkeit geschaffen, diese Inhalte in das E-Commerce-Shopsystem Salesforce Commerce Cloud zu übertragen und dort zu nutzen.
|
Im restlichen Dokument wird anstelle “Salesforce Commerce Cloud” die Kurzform “Commerce Cloud” benutzt. Damit ist immer ausschließlich die Salesforce Commerce Cloud gemeint. |
Es kombiniert die funktionalen Stärken beider Systeme, um so die besten Vorteile zu erzielen und ein erfolgreiches Gesamtsystem zu schaffen. Dieses Gesamtsystem besteht aus zwei Bereichen, die parallel und größtenteils entkoppelt voneinander arbeiten:
|
Dieses Dokument bezieht sich lediglich auf die FirstSpirit-seitigen Komponenten. Es wird vorausgesetzt, dass der Leser mit der Commerce Cloud vertraut und sicher in dessen Verwendung ist. |
ContentConnect stellt Redakteuren die folgenden Möglichkeiten zur Verfügung:
Open Commerce API (OC API)
WebDAV
Die entsprechenden Funktionalitäten werden mit der Installation und Konfiguration der Module sowohl im SiteArchitect als auch im ContentCreator bereitgestellt.
Die Pflege der Inhalte findet über die gewohnten FirstSpirit-Mittel statt. Mit FirstSpirit vertraute Redakteure benötigen daher keine darüber hinausgehenden Kenntnisse. Die Inhalte werden im Rahmen eines Deployments der Commerce Cloud zum Import bereitgestellt. Diese überträgt die Informationen in den Live-Stand.
Die Auslieferung erzeugt somit keinen Unterschied für die Commerce Cloud und ist unabhängig von der Erreichbarkeit des FirstSpirit-Servers. Auch wenn dieser beispielsweise aufgrund von Wartungsarbeiten heruntergefahren wird, beeinflusst dies die Commerce Cloud und damit die Auslieferung der deployten Inhalte nicht.
Die Verbindung von FirstSpirit und der Commerce Cloud wird über eine Architektur aus verschiedenen Komponenten realisiert (vgl. Abbildung Architektur). Diese Komponenten sind:
die auf dem FirstSpirit-Server installierten Module:
Das Zusammenspiel der einzelnen Komponenten erfolgt immer nach dem folgenden Schema:
http nach FirstSpirit übertragen, wo es für die vollständige Darstellung der Vorschau benötigt wird.
Die Übergabe der Produkte nach FirstSpirit erfolgt über die OC API-Schnittstelle der Commerce Cloud Staging Instanz.
WebDAV der Commerce Cloud Staging Instanz bereitgestellt.
Sie werden in Form von Medien und XML-Dateien in verschiedenen WebDAV-Verzeichnissen abgelegt.
Von dort werden sie über Jobs in die Library der Commerce Cloud Staging Instanz importiert.
Die Commerce Cloud stellt somit die Hauptkomponente dieser Architektur dar. Es liefert die in FirstSpirit erstellten bzw. gepflegten Inhalte an die Kunden aus und stellt sämtliche Shop-Funktionalitäten zur Verfügung. Zwischen beiden Systemen existiert lediglich eine lose Kopplung. Sie arbeiten hauptsächlich parallel zueinander. Wird der FirstSpirit-Server beispielsweise aufgrund von Wartungsarbeiten heruntergefahren, beeinflusst dies die Commerce Cloud nicht.
ContentConnect besitzt die folgenden technischen Voraussetzungen:
|
Für die fehlerfreie Arbeit mit der Commerce Cloud benötigt der FirstSpirit-Server Java 8.
Ist die Verwendung der Java-Version 7 gewünscht, müssen entsprechende Anpassungen in der |
|
Für die fehlerfreie Darstellung der Vorschau des mitgelieferten Beispielprojekts, muss Chrome verwendet werden.
Dieser kann im Menü des SiteArchitects unter |
Dieses Kapitel enthält Hinweise, die bei der Verwendung des ContentConnect-Moduls zu beachten sind.
Content Assets, die in FirstSpirit angelegt werden, bekommen von FirstSpirit eine eindeutige ID. Wird in der Commerce Cloud ein Content Asset mit exakt derselben ID angelegt, wird dieses beim Veröffentlichen von FirstSpirit überschrieben.
ContentConnect besteht aus verschiedenen Komponenten. Die Funktionalität dieser Komponenten wird in den nachfolgenden Unterkapiteln erläutert.
Das ContentConnect-Modul ist die Hauptkomponente der Verbindung zwischen FirstSpirit und der Commerce Cloud. Es hat eine maßgebliche Bedeutung für den bidirektionalen Datenaustausch zwischen dem FirstSpirit-Server und der Commerce Cloud.
Sowohl im SiteArchitect als auch im ContentCreator wird durch das Modul ein Report bereitgestellt. Dieser Report dient der Darstellung der Produktinformationen aus der Commerce Cloud. Stößt ein Redakteur eine entsprechende Abfrage an, ermittelt das Modul die gewünschten Daten und übergibt sie dem Report. Die zurückgelieferten Daten können anschließend für die Erstellung und Pflege redaktioneller Inhalte weiterverwendet werden.
Wird nach der Erstellung der Inhalte eine Generierung ausgeführt, fasst das Modul sie in Form zweier XML-Dateien zusammen. Die Dateien werden dann vom WebDAV-Modul in den Commerce Cloud Storage übermittelt. Aus diesem liest die Commerce Cloud die Daten aus und überträgt sie in den Live-Stand.
|
Das ContentConnect-Modul stellt eine API bereit, mit der projektspezifische Funktionalitäten implementiert werden können. Weitere Informationen können der mitgelieferten Javadoc-Dokumentation entnommen werden. |
Die Erstellung und Bearbeitung der redaktionellen Inhalte findet FirstSpirit-seitig statt. Ihre Übertragung in den Live-Stand erfolgt hingegen durch die Commerce Cloud. Ihm müssen die Inhalte daher bereitgestellt werden. Dafür erstellt das ContentConnect-Modul im Rahmen eines Deployments jeweils eine XML-Datei für die Library und die Slot Configuration. Sie müssen zusammen mit den referenzierten Medien an die Commerce Cloud übergeben werden.
Diese Aufgabe übernimmt das WebDAV-Modul. Es fungiert als Bindeglied zwischen FirstSpirit und der Commerce Cloud und legt die Daten im Commerce Cloud Storage ab. Aus diesem werden sie von der Commerce Cloud ausgelesen.
Im SiteArchitect ist innerhalb des Templatecodes die Möglichkeit zur Verwendung von JSTL-Tags erforderlich. Diese Möglichkeit stellt das JSTL-Modul bereit. Es muss jedoch nur dann auf dem FirstSpirit-Server installiert werden, wenn JSTL noch nicht anderweitig auf dem Server eingebunden ist.
Die Cartridge int_firstspirit_cms bietet Funktionen zum Import der in FirstSpirit erstellten redaktionellen Inhalte in die Commerce Cloud.
Hierzu enthält sie die Pipeline ContentSync, die wiederum zwei Startknoten besitzt: LIBRARY und SLOT_CONFIGURATIONS (vgl. Abbildung Pipeline Content Sync).
Über LIBRARY werden die redaktionellen Inhalte importiert.
Die Slot-Konfigurationen entsprechend über SLOT_CONFIGURATIONS.
Für beide Fälle erwartet die Pipeline die Parameter ImportFile und ImportMode.
Der Aufruf der Pipeline sollte über Job Schedules geschehen (vgl. Einrichtung der Job Schedules)
Außerdem enthält die Cartridge den JavaScript Controller RenderTemplate.
Dieser wird benötigt, um das Mapping von Commerce Cloud Render Templates auf FirstSpirit Seitenvorlagen zu realisieren
und damit das Anlegen von Detailseiten zu ermöglichen (vgl. Product Page Template Uid, Category Page Template Uid und Detailseiten).
Für die Verwendung der ContentConnect-Funktionalitäten ist die Installation und Konfiguration unterschiedlicher FirstSpirit- und Commerce Cloud-Komponenten notwendig.
In den folgenden Unterkapiteln wird zunächst die Installation und Konfiguration der FirstSpirit-seitigen Komponenten erläutert.
Die ContentConnect-Auslieferung enthält drei Module, die auf dem FirstSpirit-Server hinzugefügt werden.
Öffnen Sie für die Installation der Module den ServerManager und wählen Sie den Bereich → .
Im Hauptpanel ist eine Liste aller auf dem FirstSpirit-Server installierten Module zu sehen.
Wählen Sie nach dem Klicken auf nacheinander zunächst die mitgelieferte contentconnect-fsm-<Versionsnummer>.fsm und anschließend die WebDavDeployment-<Versionsnummer>.fsm sowie die jstl.fsm aus.
Bestätigen Sie die Auswahl jeweils mit .
Nach der erfolgreichen Installation wurden der Liste die Ordner ContentConnect, WebDavDeployment und JSTL hinzugefügt, von denen jeder Alle Rechte erhalten muss.
|
Das JSTL-Modul muss nur dann installiert werden, wenn JSTL noch nicht anderweitig auf dem Server eingebunden ist. |
|
Nach jeder Installation oder Aktualisierung eines Moduls ist ein Neustart des FirstSpirit-Servers notwendig. |
Die Installation der Module muss anschließend durch die Ergänzung des Apache Commons Codec in der Version 1.8 vervollständigt werden.
Dabei handelt es sich um eine Bibliothek, die vom WebDAV-Modul verwendet wird.
Sie benötigen das Archiv commons-codec-1.8-bin.zip, welches Sie unter der folgenden URL herunterladen können: http://commons.apache.org/proper/commons-codec
Extrahieren Sie die Datei an einer beliebigen Stelle innerhalb ihres Dateisystems und separieren Sie das commons-codec-1.8.jar.
Diese jar-Datei muss dem FirstSpirit-Server hinzugefügt werden.
Öffnen Sie dafür das Verzeichnis Ihrer FirstSpirit-Installation, wechseln Sie in den Unterordner → und kopieren Sie die jar-Datei hinein.
|
Der FirstSpirit-Server muss im Anschluss neugestartet werden. |
Um den WebDAV-Server mit https statt http zu verwenden, ist allgemein keine zusätzliche Konfiguration notwendig.
Für https wird jedoch im Allgemeinen eine lokale vom Unternehmen verwaltete Zertifizierungsstelle verwendet.
Dessen Zertifikat muss inklusive der gesamten Kette bis zum Zertifikat des WebDAV-Servers der JVM des FirstSpirit-Servers zur Verfügung gestellt werden.
|
Die JVM erwartet diese öffentlichen Zertifikate als |
Importieren Sie die öffentlichen Root- oder Zwischenzertifikate über das folgende Kommando in eine JKS-Datei und beantworten Sie die Frage, ob dem Zertifikat vertraut werden soll, mit Ja.
Dieser Vorgang muss für jedes Zertifikat wiederholt werden.
keytool -import -file cert1.crt -keystore truststore.jks –storepass changeit
Kopieren Sie den erzeugten Trust Store in das Verzeichnis → ihres FirstSpirit-Servers und fügen Sie die folgenden Zeilen der Datei → → hinzu.
wrapper.java.additional.100=-Djavax.net.ssl.trustStore=conf/truststore.jks wrapper.java.additional.101=-Djavax.net.ssl.trustStorePassword=changeit wrapper.java.additional.102=-Djavax.net.ssl.trustStoreType=JKS
|
Die Parameter müssen über einen Neustart des FirstSpirit-Servers aktiviert werden. |
Sollte der WebDAV-Server eine wechselseitige SSL-Authentifizierung erwarten, muss über die folgenden Aufrufe zunächst ein Client-Zertifikat erstellt und signiert werden.
openssl genrsa -out private.key 2048 openssl req -new -key private.key -out request.csr
Die Datei request.csr wird an die Zertifizierungsstelle versandt, die mit der Datei cert.crt antwortet.
Der private Schlüssel, das öffentliche Zertifikat und das Zertifikat der Zertifizierungsstelle müssen anschließend in einem von der JVM zu lesenden Key Store zusammengefasst werden.
cd firstspirit5/conf openssl pkcs12 -export -in public.crt -inkey private.key \ -out clientcert.p12 -CAfile authority.crt
Falls die Zertifikatskette aus einem oder mehreren Zwischenzertifikaten besteht, können diese via keytool importiert werden.
keytool -import -file intermediate1.crt -trustcacerts \ -keystore clientcert.p12 -storepass changeit
Der Key Store lässt sich über das Hinzufügen der folgenden Zeilen in die → → an die JVM des FirstSpirit-Servers übergeben.
wrapper.java.additional.103=-Djavax.net.ssl.keyStore=conf/clientcert.p12 wrapper.java.additional.104=-Djavax.net.ssl.keyStorePassword=changeit wrapper.java.additional.105=-Djavax.net.ssl.keyStoreType=PKCS12
Für den Einsatz des ContentConnect-Moduls ist eine projektspezifische Konfiguration notwendig.
Diese wird über die Projekt-Komponente vorgenommen, die dem verwendeten Projekt hinzuzufügen ist.
Öffnen Sie dafür den ServerManager und wählen Sie den Bereich → .
Im Hauptpanel ist eine Liste aller bereits vorhandenen Projekt-Komponenten zu sehen.
Wählen Sie nach dem Klicken auf die ContentConnect Project Configuration und bestätigen Sie die Auswahl mit .
Die Projekt-Komponente wird anschließend der Liste im Hauptpanel hinzugefügt und muss anschließend noch konfiguriert werden (vgl. Abbildung Projekt-Komponenten in den Projekt-Eigenschaften).
Selektieren Sie dafür den Eintrag in der Liste und öffnen Sie den zugehörigen Konfigurationsdialog über (vgl. Abbildung Konfigurationsdialog der Projekt-Komponente).
Base URL erfasst, die sich aus der URL der Commerce Cloud-Instanz und der ID der verwendeten Site ergibt:https://<SUBDOMAIN INSTANCE>.demandware.net/s/<SITE ID>Base URL handelt es sich um ein Pflichtfeld.
Client ID anzugeben, die zur Verwendung der Open Commerce Shop API benötigt wird und deshalb ebenfalls eine Pflichtangabe ist.
|
Die |
LibraryManager und SlotConfigurationManager.
Falls eine solche Schnittstelle verwendet wird, muss in diesem Konfigurationsfeld ein Passwort hinterlegt werden,
andernfalls kann das Feld leer bleiben.
Das einzutragende Passwort wird wie die Client ID während der Registrierung der Client-Applikation bei der Commerce Cloud erzeugt.
|
Es werden maximal die ersten neun angegebenen Schlüssel-Wert-Paare genutzt, da die Commerce Cloud nicht mehr als neun Refinements akzeptiert. Das Format der Werte der Schlüssel-Wert-Paare entspricht dem von der Commerce Cloud erwarteten Format für Refinement-Werte. Es können also mehrere Werte sowie Wertmengen für ein Refinement angegeben werden:
|
|
Die Filterung nach einer Kategorie geschieht ebenfalls über ein Refinement, weshalb zwei Sonderfälle zu beachten sind: Im ersten Fall
In diesem Fall liegen insgesamt zehn Refinement-Definitionen vor, was unzulässig ist. Deshalb wird ein Refinement aus der Konfiguration ignoriert, um stattdessen die Kategorie-Filterung zu ermöglich. Im zweiten Fall
In diesem Fall gibt es eine doppelte Definition für das Kategorie-Refinement |
locale in Storefront-Anfragen nicht verwendet.
storefront angegeben werden.
storefront Users gehörenden Passworts.
|
In der gewählten Seitenvorlage ist zwingend das Feld <CMS_INPUT_TEXT name="dw_item_id" hidden="yes" useLanguages="no"> <LANGINFOS> <LANGINFO lang="*" label=""/> </LANGINFOS> </CMS_INPUT_TEXT> |
Default Folder (Product Pages) getroffene Auswahl durch einen Redakteur geändert werden kann.
Initial ist die Funktion aktiviert.
Ist sie deaktiviert, wird die entsprechende Eingabekomponente im Dialog zur Erstellung einer Detailseite versteckt.
Der Redakteur besitzt in diesem Fall keine Möglichkeit, den Menüpunkt einer neu erstellten Detailseite zu wählen bzw. ändern.
|
Wird die Checkbox deaktiviert, muss zwingend der Referenzname eines Struktur-Ordners im Feld |
Über dieses Konfigurationsfeld kann das Mapping von Seitenvorlagen, für das Anlegen von Kategorie-Detailseiten über den Kategorie-Report, konfiguriert werden. Dabei gelten folgende Regeln:
|
Wir empfehlen, separate Vorlagen für Produkt- und Kategorie-Detailseiten zu verwenden. |
Editable Folder (Product Pages) kann an dieser Stelle festgelegt werden, ob Redakteure die im Feld Default Folder (Category Pages) getroffene Auswahl ändern können.
Initial ist die Funktion aktiviert.
Ist sie deaktiviert, wird die Auswahlmöglichkeit im Dialog zur Erstellung einer Detailseite versteckt.
Der Redakteur besitzt in diesem Fall keine Möglichkeit, den Menüpunkt für eine neue Detailseite zu wählen bzw. zu ändern.
|
Wird die Checkbox deaktiviert, muss zwingend der Referenzname eines Struktur-Ordners im Feld |
|
Es ist zu beachten, dass nur der Code aus dem html-Kanal des Skripts ausgeführt wird. |
View Type Priority der zu berücksichtigenden Bildgrößen definiert werden.large) Bild ermittelt und bei dessen Existenz verwendet.
Liegt jedoch kein großes Bild vor, wird anschließend das mittelgroße (medium) bzw. gegebenenfalls das kleine (small) Bild abgerufen.
|
Da das Feld keine Pflichteingabe erwartet, kann es vorkommen, dass keine Priorität definiert wird und das Feld leer bleibt. In diesem Fall werden Suchergebnisse für eine Produktabfrage ohne ein Bild dargestellt. |
Image Service bereit.
Dieser stellt zusätzliche Bilder für die verwendeten Produktbilder bereit.
Ist seine Verwendung gewünscht, ist an dieser Stelle lediglich die zugehörige Base URL anzugeben.
|
Die Angabe der |
Use Category Search? deaktiviert.
In diesem Fall lässt sich eine Produktsuche nicht auf eine Kategorie filtern.
Die zugehörige Dropdown-Liste wird währenddessen im Report ausgeblendet.
Ist eine solche Filterung nach Kategorien gewünscht, muss die Checkbox aktiviert werden.
Client ID, die Base URL und - wenn vorhanden - die Image Service Base URL berücksichtigt.
|
Da einige Vorlagen JSTL-Code beinhalten, muss vor dem Import der Präsentationskanal des Vorlagensatzes Des Weiteren muss die verwendete Konvertierungsregel die folgende Zeile enthalten: Abbildung 7. html-Vorlagensatz |
Für die Vorschau und den ContentCreator müssen zwei Web-Komponenten hinzugefügt werden.
Öffnen Sie hierfür den ServerManager und wählen Sie den Bereich → .
Innerhalb des Hauptpanels sind verschiedene Registerkarten zu sehen, die jeweils eine Liste der bereits vorhandenen Web-Komponenten enthalten.
Selektieren Sie nach dem Klicken auf für die initial ausgewählte Registerkarte Vorschau die ContentConnect Web Resources und FS_JSTL_WebApp und bestätigen Sie die Auswahl mit .
Wiederholen Sie diesen Vorgang für den ContentCreator.
Die Liste im Hauptpanel wird anschließend für beide Registerkarten um die jeweiligen Web-Komponenten ergänzt (vgl. Abbildung Web-Komponenten in den Projekt-Eigenschaften).
Die Web-Komponenten müssen auf einem aktiven Webserver installiert und danach aktiviert werden.
Dieser kann über die Auswahlbox gewählt werden.
Detaillierte Informationen zum Hinzufügen von Web-Komponenten finden Sie in der FirstSpirit Dokumentation für Administratoren.
Für die Funktionalitäten des ContentConnect-Moduls sind einige projektspezifische Informationen erforderlich. Die Informationen werden in den Projekteinstellungen angegeben.
Die Vorlage ist in den Projekt-Eigenschaften auszuwählen und muss dafür im Projekt existieren.
Legen Sie sie zunächst an, wenn dies nicht zutreffen sollte.
Andernfalls öffnen Sie den ServerManager und wechseln Sie auf den Bereich → .
Selektieren Sie anschließend die Einstellungs-Seite über den entsprechenden Auswahlbutton (vgl. Abbildung Optionen in den Projekt-Eigenschaften).
Ein Klick auf den Button speichert die vorgenommenen Änderungen.
In diesem Kapitel wird die Installation und Konfiguration der Commerce Cloud-seitigen Komponenten erläutert.
In der Auslieferung ist die Cartridge int_firstspirit_cms enthalten,
die zunächst in die Commerce Cloud übertragen werden muss.
Verschiedene Methoden hierzu beschreibt die Commerce Cloud-Dokumentation unter
Developing your storefront → Development components → Cartridges.
Anschließend muss die Cartridge allen Sites, die FirstSpirit-Inhalte empfangen sollen, sowie der Business-Manger-Site hinzugefügt werden. Entsprechende Instruktionen finden sich in der Commerce Cloud-Dokumentation unter Getting started → Getting started for developers → Registering your cartridge.
Um die von FirstSpirit generierten Inhalte und Slot-Konfigurationen in die Commerce Cloud zu importieren, ist für jede Site ein Job Schedule in der Commerce Cloud anzulegen. Die Cartridge definiert dazu zwei Job Steps:
custom.FirstSpirit.ImportLibrary importiert die von FirstSpirit generierten Inhalte in die Commerce Cloud
custom.FirstSpirit.ImportSlotConfigurations import die von FirstSpirit generierten Slot-Konfigurationen in die Commerce Cloud
Beide besitzen die Pflichtparameter Import File und Import Mode:
IMPEX-Verzeichnis.
|
Die Commerce Cloud-Dokumentation enthält eine Beschreibung der verschiedenen Import Modes: Administering your organization → Import and export → Import modes. |
Der Job Schedule sollte einen Workflow mit zwei parallelen Flows enthalten. Jeder Flow kann dann einen der beiden oberen Job Steps aufrufen.
|
Allgemeine Informationen zum Anlegen von Job Schedules finden sich in der Commerce Cloud-Dokumentation unter Administering your organization → Import and export → Importing data into and exporting data from the instance database → Job management and scheduling → Creating a new job schedule |
Neben der Cartridge enthält die Auslieferung im Verzeichnis metadata außerdem eine Export-Datei eines Job Schedules,
der als Referenz genutzt werden kann und die Anlage der verschiedenen Job Schedules vereinfacht.
|
Da für jede Site ein Job anzulegen ist,
muss das Attribut |
Nach dem Import sind weitere Anpassung am Job Schedule notwendig.
Der Scope beider Job Flows muss auf die richtige Site gesetzt werden.
Ebenso ist der Import File-Parameter in beiden Job Steps anzupassen,
sodass er den korrekten Pfad enthält.
|
Der Scope der Flows sowie der Parameter |
Nach der Installation und Konfiguration der verschiedenen Komponenten sowie dem Import der Vorlagen müssen innerhalb des Projekts diverse Anpassungen vorgenommen werden. Die dafür notwendigen Schritte werden in den nachfolgenden Unterkapiteln erläutert.
Für die Verbindung zwischen FirstSpirit und der Commerce Cloud sind einige projektspezifische Informationen unentbehrlich (vgl. Abbildung Projekteinstellungen). Sie werden über das Formular der Projekteinstellungen erfasst und sind innerhalb des verwendeten Projekts anzugeben.
http oder https miteinander kommunizieren sollen.
Online (protected) aktiviert wird.
Besteht diese Einschränkung, muss in FirstSpirit der User storefront angegeben werden.
Durch die Aktivierung der Checkbox werden die Felder User und Password eingeblendet.
storefront angegeben werden.
storefront Users gehörenden Passworts.
Des Weiteren werden mit der Vorlage zwei XML-Kollektoren und ein Produkt-Manager initialisiert, die in den anderen Seiten- und Absatzvorlagen des Projekts genutzt werden. In diesen Seiten- und Absatzvorlagen wird festgelegt, welche Daten an die Commerce Cloud übergeben werden sollen. Während der Generierung werden die Daten auf Basis dieser Festlegungen gesammelt und die XML-Kollektoren gefüllt.
|
Bestehen für die XML-Kollektoren projektspezifische Anforderungen, so können sie über die Methoden der Klasse Informationen zum Aufruf des Produkt-Managers sind im Javadoc der Klasse |
Die Commerce Cloud erwartet alle an ihr übermittelten Daten in Form von XML-Dateien. Aus diesem Grund werden die im ersten Schritt der Generierung in die XML-Kollektoren geschriebenen Informationen im zweiten Schritt ausgelesen und in jeweils eine XML-Datei geschrieben.
Dafür muss der Generierungszeitpunkt der Dateien bestimmbar sein und sichergestellt werden, dass die Befüllung der XML-Kollektoren bereits abgeschlossen wurde.
Diese Aufgabe übernimmt die XML-Vorlage.
Sie besitzt eine Abfrage, mit der während der Generierung die Strukturvariable dwre_xmlGeneration ausgewertet wird.
Abfrage der Strukturvariablen dwre_xmlGeneration.
$CMS_IF(!#global.preview)$
$CMS_IF(!dwre_xmlGeneration.equals("true"))$
$CMS_SET(#global.stopGenerate,true)$
$CMS_END_IF$
$CMS_VALUE(xmlCollector.getXml(true))$
$CMS_END_IF$
Die Variable wird erst im zweiten Schritt der Generierung über den Auftrag auf true gesetzt und besitzt ansonsten den Wert false.
Damit werden auch die benötigten XML-Dateien erst zu diesem Zeitpunkt erzeugt.
Ohne die Abfrage würden die XML-Kollektoren bereits im ersten Schritt ausgelesen.
Dies hätte jedoch inkonsistente Datenstände zur Folge.
|
Mit der Vorlage lassen sich zwei XML-Dateien erzeugen. Dies erfolgt in beiden Fällen über einen Kollektor, für den jeweils eine auf der XML-Vorlage basierende Seitenreferenz benötigt wird. Im Formular der zugehörigen Seite muss der entsprechende XML-Kollektor ausgewählt werden. |
|
Im Eigenschaften-Tab der Vorlage muss als Dateiendung |
Die Generierung der folder-Tags erfordert eine projektspezifische Erweiterung der XML-Vorlage in Form einer Navigationsfunktion,
die die notwendigen XML-Elemente erzeugt.
Die Ausgabe dieser Funktion muss folglich ebenfalls an einer passenden Stelle ergänzt werden,
worauf Kommentare in der importieren Vorlage nochmals hinweisen.
Das mitgelieferte Demoprojekt enthält eine beispielhafte Implementierung einer solchen Navigationsfunktion.
Neben einigen technischen Formatvorlagen wird auch die Vorlage Preview Generation importiert.
Über sie wird mithilfe von JSTL eine Abfrage an die Commerce Cloud versandt und das HTML-Gerüst der Seite angefordert.
Dieses Gerüst wird durch die Ersetzung der bestehenden Platzhalter mit FirstSpirit-Inhalten angereichert.
Auf diesem Weg kann den Redakteuren die Seite in der Vorschau des SiteArchitects bzw. im ContentCreator dargestellt werden.
Des Weiteren dient die Vorlage der Personalisierung. Sie ermöglicht die Anpassung der Darstellung bei der Selektion spezieller Zielgruppen. Ist auch die Filterung auf bestimmte Zeiträume gewünscht, muss der Code entsprechend erweitert werden.
Die Vorlage übernimmt somit mehrere Aufgaben und besitzt daher eine grundlegende Bedeutung innerhalb des Projekts.
Die Commerce Cloud besitzt verschiedene Seitentypen, die neben einer URL zum Teil eine ID besitzen.
Für die Darstelllung in der Vorschau bzw. im ContentCreator muss FirstSpirit anhand dieser Parameter die passende URL erzeugen, um die zugehörige Seite in der Commerce Cloud abfragen zu können.
Dafür wurde die Formatvorlage Create Preview URL bereitgestellt.
Die Vorlage erwartet sowohl den Typ als auch - wenn sie existiert - die ID der zugehörigen Commerce Cloud-Seite. Aus diesem Grund muss jede verwendete Seitenvorlage die folgenden beiden Eingabekomponenten bereitstellen:
Radiobutton und Textfeld.
<CMS_INPUT_RADIOBUTTON name="pt_dwre_previewType" gridWidth="3" hFill="yes"> <ENTRIES> <ENTRY value="home"> <LANGINFOS> <LANGINFO lang="*" label="Home"/> </LANGINFOS> </ENTRY> <ENTRY value="page"> <LANGINFOS> <LANGINFO lang="*" label="Page"/> </LANGINFOS> </ENTRY> <ENTRY value="folder"> <LANGINFOS> <LANGINFO lang="*" label="Folder"/> </LANGINFOS> </ENTRY> <ENTRY value="search"> <LANGINFOS> <LANGINFO lang="*" label="Search"/> </LANGINFOS> </ENTRY> </ENTRIES> <LANGINFOS> <LANGINFO lang="*" label="Preview Page Type"/> </LANGINFOS> </CMS_INPUT_RADIOBUTTON> <CMS_INPUT_TEXT name="pt_dwre_previewPageId" hFill="yes" hidden="no"> <LANGINFOS> <LANGINFO lang="*" label="SFCC Preview Page Identifier (Page-Show:CID / Page-Search:CGID)"/> </LANGINFOS> </CMS_INPUT_TEXT>
Die Weiterverarbeitung der mit diesen Komponenten erfassten Daten erfolgt über die initial importierten Formatvorlagen Default Page Header und Preview Generation.
Sie müssen über einen CMS_RENDER-Aufruf in den verwendeten Seitenvorlagen referenziert werden.
Dabei ist zu beachten, dass die beiden Formatvorlagen nur die FirstSpirit-Vorschau beeinflussen.
Es sollte daher eine entsprechende Unterscheidung vorgenommen werden:
Referenzierung der Formatvorlagen.
$CMS_IF(!#global.preview)$ [...] // Codepointer 1 $CMS_ELSE$ $CMS_RENDER(template:"default_page_header")$ [...] // Codepointer 2 $CMS_RENDER(template:"preview_generation")$ $CMS_END_IF$
Codepointer 1
Im sich nicht auf die Vorschau beziehenden Teil der Abfrage ist festzulegen, mit welchen Daten die in den Projekteinstellungen initialisierten XML-Kollektoren gefüllt werden sollen.
Dies erfolgt über CMS_SET-Aufrufe und die add-Methoden der Kollektoren.
Das mit dem Modul ausgelieferte Projekt enthält beispielsweise innerhalb der Seitenvorlagen den nachstehenden Aufruf:
$CMS_SET(void,ps_xmlCollector.addContentAttribute({
"name":"display-name",
"value":#global.node.getDisplayName(#global.language).toString(),
"attributes":{"xml:lang":set_xml_lang} }))$`
Der Aufruf erzeugt das Tag display-name, das in der generierten XML-Datei über folgenden Aufbau verfügt:
<display-name xml:lang="en"><![CDATA[About Us]]></display-name>
Es besitzt als Wert den Anzeigenamen der aktuellen Seite. Außerdem wird ihm die Sprache als Parameter mitgegeben.
Codepointer 2
Zwischen den beiden CMS_RENDER-Aufrufen findet die Ersetzung der aus der Commerce Cloud stammenden Platzhalter statt.
Dafür ist zu definieren, welcher Platzhalter an dieser Stelle durch welche FirstSpirit-Inhalte auszutauschen ist.
Dies erfolgt ebenfalls über CMS_SET-Aufrufe und die Methoden stringToReplace bzw. stringToInsert.
Das mitgelieferte Projekt enthält dafür beispielsweise innerhalb der Seitenvorlage Homepage den nachfolgenden Aufruf.
Durch ihn wird in diesem Fall in der Vorschau und im ContentCreator statt des Platzhalters der in FirstSpirit gepflegte Inhaltsbereich fs_home_cycle angezeigt.
$CMS_SET(void, stringToReplace.add( "<!-- CMS-CONTENT-CYCLE-START -->(?s:.)*<!-- CMS-CONTENT-CYCLE-END -->"))$ $CMS_SET(stringToInsert[stringToReplace.size-1])$ <div$CMS_VALUE(editorId(element:#global.page.body("fs_home_cycle")))$> $CMS_VALUE(#global.page.body("fs_home_cycle"))$ </div> $CMS_END_SET$
Beide Punkte müssen projektspezifisch erfolgen und können im mitgelieferten Beispielprojekt nachvollzogen werden.
|
Zur Verwendung der Content Integration API sind weitere Punkte zu beachten, die in Kapitel Seitenvorlage für redaktionelle Inhalte beschrieben sind. |
Die Commerce Cloud erwartet alle an ihr übermittelten Daten in Form von XML-Dateien.
Sie dürfen erst nach der Befüllung der XML-Kollektoren erzeugt werden, da ansonsten von Datenverlusten auszugehen ist.
Die Steuerung des Erstellungszeitpunkts der Dateien erfolgt über die Strukturvariable dwre_xmlGeneration, die manuell anzulegen ist.
Öffnen Sie dafür die Strukturverwaltung ihres Projekts und selektieren Sie die Registerkarte → , bevor Sie den Bearbeitungsmodus aktivieren.
Vergeben Sie dann in dem sich über den Button öffnenden Dialog den Namen dwre_xmlGeneration.
Bestätigen Sie die Angabe mit und vergeben Sie im sich darauf öffnenden Dialog den Wert false.
Schließen Sie den Dialog, indem Sie den Wert .
Im zweiten Schritt der Generierung erhält die Variable über den Auftrag den Wert true.
Eine Abfrage innerhalb der XML-Vorlage regelt auf diesem Weg den Erstellungszeitpunkt der an die Commerce Cloud zu übermittelnden XML-Dateien.
Sowohl im SiteArchitect als auch im ContentCreator wird durch das ContentConnect-Modul ein Report bereitgestellt. Dieser Report dient der Darstellung der Produktinformationen aus der Commerce Cloud. Wenn die Projektkomponente entsprechend konfiguriert wurde, kann die Suche auf eine Kategorie und ihre Unterkategorien beschränkt werden. Die Abbildung Produkte-Report zeigt den Report links ohne und rechts mit dem Kategorie-Filter.
Um eine Produktsuche durchzuführen, muss mindestens einer der beiden Parameter (Kategorie, Suchbegriff) angegeben werden. Falls eine Kategorie ausgewählt wird, zeigt der Report alle Produkte dieser Kategorie an, die zum eingegebenen Suchbegriff passen. Sollte dieser Begriff leer sein, werden alle Produkte der ausgewählten Kategorie abgerufen. Wird hingegen keine spezielle Kategorie selektiert, werden alle Kategorien nach dem eingegebenen Begriff durchsucht. Wenn der Kategorie-Filter inaktiv ist, wird keine Kategorie zur Filterung genutzt und der Report verhält sich entsprechend.
|
In der Commerce Cloud existieren zu einem Master-Produkt unterschiedliche Produktvarianten, die bei einer Standardsuche nicht im Report angezeigt werden. Über die Suche nach ihrer ID können sie jedoch ebenfalls gefunden und verwendet werden |
|
Neben dem Produkte-Report bietet das ContentConnect-Modul auch einen optionalen Kategorie-Report. Die Daten dieses Reports können analog zu den Daten des Produkte-Reports verwendet werden. |
Die Daten des Reports können für die Erstellung und Pflege redaktioneller Inhalte weiterverwendet werden. Dafür müssen den Redakteuren entsprechende Mittel bereitgestellt werden. Dies ist grundsätzlich auf verschiedenste Weisen möglich. Die jeweils optimale Umsetzung muss daher immer individuell auf Basis der bestehenden projektspezifischen Anforderung ermittelt werden.
Innerhalb des mitgelieferten Beispielprojekts können sowohl mehrere Commerce Cloud-Produkte über eine FS_LIST als auch nur ein einziges Produkt über eine Verweisvorlage referenziert werden.
Bei der Verwendung der FS_LIST wird ihr für jedes gewählte Produkt ein neuer Eintrag hinzugefügt und die Produktinformationen in diesem gespeichert.
Im Gegensatz dazu werden die Informationen bei der Verweisvorlage direkt im Formular hinterlegt.
Beide Wege divergieren bei der Implementierung lediglich in einem Punkt, der im nachfolgenden Kapitel Formular erläutert wird.
Abhängig vom Anwendungsfall können bei der Ausgabe der referenzierten Produkte unterschiedliche Informationen erforderlich sein. Bei der Darstellung "ähnlicher Produkte" bietet sich beispielsweise die Verwendung allgemeiner Daten an, während für sogenannte "Hot Spots" spezifische Variantionsattribute benötigt werden. Die Ermittlung und Ausgabe der Informationen für diese beiden Fälle wird in den nachfolgenden Unterkapiteln Ausgabe allgemeiner Produktinformationen und Verlinkung von Produktvarianten beschrieben.
Die beiden im vorgehenden Kapitel erwähnten Wege zur Referenzierung von Commerce Cloud-Produkten divergieren nur in einem Punkt.
Aus diesem Grund wird in diesem Kapitel vorrangig die Umsetzung der FS_LIST skizziert und auf den Unterschied zur Verweisvorlage lediglich an entsprechender Stelle hingewiesen.
Die FS_LIST ist im Beispielprojekt in der Absatzvorlage Featured Products definiert, deren Formular sich außerdem aus den beiden Buttons clickHandler und dropHandler zusammensetzt.
Beide Buttons verwenden die Klasse Demandware_ProductDropHandler, die ein Bestandteil des ContentConnect-Moduls ist und die Übertragung eines Commerce Cloud-Produkts regelt.
<FS_LIST name="st_productList" hFill="yes" height="400"> <DATASOURCE type="inline" useLanguages="yes"> <LABELS> <LABEL lang="*">#item.name</LABEL> </LABELS> [...] <TEMPLATES source="linktemplates"> <TEMPLATE uid="list_product_link"/> </TEMPLATES> </DATASOURCE> </FS_LIST> <FS_BUTTON name="dropHandler" icon="media:drop_zone_product" noBreak="yes" onDrop="class:DemandwareConnect_ProductDropHandler" style="link"> <DROPTYPES> <MIME type="application/x-java-serialized-object" classname="com.espirit.moddev.demandware.products.Product"/> </DROPTYPES> <PARAMS> <PARAM name="list">#field.st_productList</PARAM> <PARAM name="id">id</PARAM> <PARAM name="name">name</PARAM> </PARAMS> </FS_BUTTON> <FS_BUTTON name="clickHandler" onClick="class:DemandwareConnect_ProductDropHandler"> <LANGINFOS> <LANGINFO lang="*" label="Add product from selection"/> </LANGINFOS> <PARAMS> <PARAM name="list">#field.st_productList</PARAM> <PARAM name="id">id</PARAM> <PARAM name="name">name</PARAM> </PARAMS> </FS_BUTTON>
Beide Buttons werden auch in der Verweisvorlage Product Hot Spot verwendet.
Dort müssen die Parameter der Buttons jedoch anders definiert werden:
<PARAMS> <PARAM name="id">#field.id</PARAM> <PARAM name="name">#field.name</PARAM> <PARAM name="variationAttributes">#field.variationAttributes</PARAM> </PARAMS>
Dieser Unterschied basiert auf der Tatsache, dass die Felder id und name im Formular der Verweisvorlage parallel zu den beiden Buttons platziert sind.
Sie werden daher über den vorangestellten Ausdruck #field direkt angesprochen.
In der Absatzvorlage Featured Products sind die Buttons hingegen parallel zur FS_LIST angeordnet und die Felder id und name in der von ihr referenzierten Verweisvorlage list_product_link enthalten.
Die beiden Buttons im Formular der Verweisvorlage besitzen außerdem den Parameter variationAttributes, der ein verstecktes Textfeld anspricht.
Dieses wird für die Persistierung der einem Produkt zugehörigen spezifischen Variationsattribute verwendet.
Da die Absatzvorlage Featured Products lediglich der Ausgabe allgemeiner Produktinformationen dient, benötigen die Buttons in ihrem Formular diesen Parameter nicht.
Die Buttons ermöglichen den Redakteuren eine schnelle und unkomplizierte Referenzierung der Commerce Cloud-Produkte in FirstSpirit, ohne dass dabei der Client verlassen werden muss. Andernfalls müssten die Produktinformationen in der Commerce Cloud ermittelt und dann manuell übertragen werden. Pro FirstSpirit-Client wird immer nur einer der beiden Buttons angezeigt.
Wie bereits zuvor erwähnt, sind die Buttons spezifisch für jeweils einen der beiden FirstSpirit-Clients. Sie müssen daher im entsprechend anderen Client ausgeblendet werden. Diese Anforderung wird über die Regeln gesteuert, die sowohl in der genannten Absatz- als auch in der Verweisvorlage definiert sind.
Die erste Abfrage aktiviert den Button clickHandler, wenn ein im Report dargestelltes Commerce Cloud-Produkt in die Zwischenablage kopiert wurde.
Die letzten beiden Abfragen prüfen, ob der aktuelle Redakteur sich im ContentCreator befindet.
Befindet er sich im SiteArchitect, wird der Button clickHandler eingeblendet.
Andernfalls ist der Button dropHandler sichtbar.
<RULES> <ON_EVENT> <SCHEDULE service="DemandwareConnect_ClipboardFilled" id="product_link_clipboard_check"> <!-- Some FS versions complain about an invalid rule definition without a parameter --> <PARAM name="dummy"> <TEXT>dummy</TEXT> </PARAM> </SCHEDULE> <DO> <PROPERTY source="clickHandler" name="EDITABLE" /> </DO> </ON_EVENT> <ON_EVENT> <WITH> <NOT> <PROPERTY source="#global" name="WEB"/> </NOT> </WITH> <DO> <PROPERTY source="clickHandler" name="VISIBLE"/> </DO> </ON_EVENT> <ON_EVENT> <WITH> <PROPERTY source="#global" name="WEB"/> </WITH> <DO> <PROPERTY source="dropHandler" name="VISIBLE"/> </DO> </ON_EVENT> </RULES>
Existiert im Formular der verwendeten Vorlage das Textfeld variationAttributes, öffnet sich bei der Referenzierung eines Master-Produkts über einen der beiden Buttons ein zusätzlicher Dialog.
Dieser stellt alle dem ausgewählten Produkt zugehörigen Variationsattribute dar, über die sich die Produktauswahl spezifizieren lässt.(vgl. Abbildung Spezifikation eines Produkts).
Ergibt sich durch die Spezifikation die Definition einer bestimmten Produktvariante, werden in den Feldern id und name der Verweisvorlage bzw. der FS_LIST die Informationen dieser Variante gespeichert.
Andernfalls werden die Id und der Name des Master-Produkts übernommen und die im Dialog definierten Variationsattribute in Form eines JSONs im versteckten Feld variationAttributes persistiert.
Für die Darstellung referenzierter Produkte in der Vorschau können mithilfe des Produkt-Managers weitere Produktinformationen abgefragt werden. Der Produkt-Manager wird in den Projekteinstellungen initialisiert, deren Vorlage während der Konfiguration der Projektkomponente in das Projekt importiert wurde. Je nach Anwendungsfall können mit ihm sowohl spezifische Variationsattribute als auch allgemeine Produktinformationen ermittelt werden.
Dieses Kapitel skizziert die Idee einer Liste "ähnlicher Produkte". In diesem Fall werden lediglich allgemeine Informationen, wie beispielsweise der Name und der Preis eines Produkts, benötigt. Spezifische Attribute sind hingegen an dieser Stelle nicht von Bedeutung.
Das nachfolgende Beispiel basiert auf der Annahme, dass für die Referenzierung der Produkte die zuvor beschriebene FS_LIST verwendet wurde.
Es kann anhand der Absatzvorlage Featured Products nachvollzogen werden.
Jedes in der FS_LIST referenzierte Produkt wird beim Durchlaufen der FOR-Schleife zunächst über den Produkt-Manager geladen.
Befindet sich der Redakteur in der Vorschau, werden anschließend durch die Verwendung einfacher Getter-Methoden das Produktbild, der Name und der Preis ermittelt und dargestellt.
$CMS_FOR(for_product,st_productList)$
$CMS_IF(!for_product.id.isEmpty)$
$CMS_SET(set_product,ps_productManager.loadProduct(for_product.id))$
[...]
$CMS_IF(!#global.preview)$
[...]
$CMS_ELSE$
$-- FirstSpirit Preview --$
<li>
<div class="product-tile">
<div class="product-image">
<a class="thumb-link" href="#" title="">
<img src="$CMS_VALUE(set_product.getImageUrl(set_width,set_height))$">
</a>
</div>
<div class="product-name">
<a class="name-link" href="#">
$CMS_VALUE(set_product.getName())$
</a>
<div class="product-price">
<span class="price-sales">
$CMS_VALUE(set_product.getCurrency())$
$CMS_VALUE(set_product.getPrice().format("0.00"))$
</span>
</div>
</div>
[...]
</div>
</li>
$CMS_END_IF$
$CMS_END_IF$
$CMS_END_FOR$
Im Gegensatz zur im vorhergehenden Kapitel beschriebenen Darstellung allgemeiner Daten können mithilfe des Produkt-Managers auch spezifische Produktinformationen abgefragt werden.
Dieses Kapitel beschreibt die Idee sogenannter "Hot Spots". Dabei handelt es sich um gezielte Verweise auf spezifische Produktvarianten. Für sie werden die der jeweiligen Variante zugehörigen Variationsattribute benötigt. Die allgemeinen Informationen sind hingegen an dieser Stelle nicht von Bedeutung.
Das nachfolgende Beispiel basiert auf der Annahme, dass für die Referenzierung eines Produkts die zuvor beschriebene Verweisvorlage Product Hot Spot verwendet wurde.
Anhand der Vorlage lässt sich das Beispiel nachvollziehen.
Für ein über die Verweisvorlage referenziertes Produkt wird zunächst ein Link auf die Commerce Cloud-Pipeline LinkProduct generiert und diesem die Id des Produkts übergeben.
Handelt es sich bereits um eine spezifische Variante, ist das Feld variationAttributes leer.
Andernfalls lädt der Produktmanager nacheinander alle in dem Feld gespeicherten Variationsattribute, die bei der Referenzierung des Produkts definiert wurden.
Für jedes dieser Attribute wird dessen Id (z.B. "Farbe") sowie der gewählten Wert (z.B. "gelb") ermittelt und aus ihnen eine per "&"-Zeichen separierte Liste erzeugt.
Der initial erzeugte Link auf die Commerce Cloud-Pipeline LinkProduct wird abschließend um diese Liste ergänzt.
$CMS_IF(!#global.preview)$
$CMS_SET(set_lt_link,"$link-product:pid="+id+"$&")$
$CMS_IF(!variationAttributes.isEmpty)$
$CMS_SET(set_attributes, ps_productManager.convertVariationValuesJSON2List(variationAttributes).map(x -> x.key + "=" + x.value).toString("&"))
$CMS_SET(set_lt_link, set_lt_link + set_attributes)$
$CMS_END_IF$
$CMS_END_IF$
<a href="$CMS_VALUE(set_lt_link)$"> ... </a>
Über den entsprechenden Report können sowohl für Produkte als auch für Kategorien jeweils Detailseiten angelegt werden. Zur Verwendung dieses Features muss in der Projekt-Komponente definiert werden, auf welchen Vorlagen diese Detailseiten basieren und wo sie in der Struktur eingebunden werden sollen.
Ein Objekt im Report kann bezüglich seiner Detailseite einen von drei Zuständen besitzen:
Die drei Fälle werden unterschiedlich visualisiert und in den nachfolgenden Unterkapiteln beschrieben.
|
Da die Objekte im Report nicht permanent aktualisiert werden, kann es zu Abweichungen in der Visualisierung kommen. |
Objekte, die noch keine Detailseite besitzen, werden im Report durch ein graues Icon markiert (vgl. Abbildung Anlegen einer Detailseite).
Wurde in der Projekt-Komponente eine Seitenvorlage definiert, erscheint beim Überfahren eines solchen Objekts die Schaltfläche .
Per Klick auf diese Schaltfläche öffnet sich ein zweigeteilter Dialog, mit dem sich für das entsprechende Objekt eine Detailseite anlegen lässt.
Der obere Teil des Dialogs ist der Struktur-Auswahl-Bereich, der automatisch eingefügt wird und damit immer gleich ist.
Er stellt dem Redakteur die Möglichkeit zur Verfügung, innerhalb der Struktur die Menüebene auszuwählen, in der die neue Detailseite erzeugt wird.
Potentiell ist die entsprechende Eingabekomponente schon vorbelegt.
Dann wurde im Konfigurationsdialog der Projekt-Komponente bereits ein Struktur-Ordner definiert.
Es steht dem Redakteur jedoch frei, diese Auswahl anzupassen.
|
Unter Umständen ist der |
Im Gegensatz zum Struktur-Auswahl-Bereich ist der untere Formular-Bereich immer projektspezifisch.
Er zeigt das Formular der in der Projekt-Komponente angegebenen Seitenvorlage.
In ihm gelten außerdem die in der Vorlage definierten Regeln.
Die folgende Abbildung zeigt einen beispielhaften Dialog:
Ein Klick auf erzeugt die Seitenreferenz der Detailseite in der zuvor gewählten Menüebene. Die zugehörige Seite wird in einem festem Ordner in der Inhalte-Verwaltung erstellt.
Ist innerhalb der Projekt-Komponente außerdem ein Skript angegeben, so wird dieses vor und nach der Erzeugung der Detailseite ausgeführt.
|
Es ist zu beachten, dass nur der Code aus dem html-Kanal des Skripts ausgeführt wird. |
Diesem Skript werden die folgenden Parameter übergeben:
| Datentyp | Objektname | Beschreibung |
|---|---|---|
BaseContext | context | Der Kontext, in dem das Skript ausgeführt wird. |
boolean | beforeInstantiation |
|
KeyProvider | keyProvider | Das Objekt, für das eine Detailseite angelegt wird. Hierbei handelt es sich entweder um ein |
|
Eine Erläuterung der Schnittstellen |
Nach der vollständigen Erzeugung der Detailseite und dem Ausführen des Skriptes wird die neu erstellte Seite aufgerufen.
Objekte, für die bereits eine Detailseite existiert, werden im Report durch einen grünes Icon markiert (vgl. Abbildung Produkt mit Detailseite).
Sie erhalten beim Überfahren die Schaltfläche , mit der die zugehörige Detailseite aufgerufen werden kann.
Besitzt ein Objekt eine Detailseite, für die jedoch die Seitenreferenz oder die zugrunde liegende Seite nicht gefunden werden kann, so wird das Objekt im Report mit einem rotes Icon markiert (vgl. Abbildung Objekt mit Defekt).
Solche Objekte erhalten beim Überfahren die Schaltfläche .
Ein Klick auf diese Schaltfläche öffnet einen Dialog, der weitere Informationen bereit hält.
Für die Übermittlung der in FirstSpirit erstellten Inhalte in den Commerce Cloud Storage wird ein Auftrag benötigt, der mindestens die nachfolgend erläuterten Aktionen enthält (vgl. Abbildung Aktionen des Generierungsauftrags). Zur Verwendung der Content Integration API ist darüber hinaus eine weitere Aktion erforderlich.
Öffnen Sie für den benötigten Auftrag den ServerManager und wählen Sie den Bereich → .
Fügen Sie dort einen neuen Standard-Auftrag hinzu oder bearbeiten Sie einen bereits bestehenden Auftrag.
Weitere Informationen zur Erstellung eines Auftrags finden Sie auch in der FirstSpirit Dokumentation für Administratoren.
Für das Deployment der für die Commerce Cloud relevanten Inhalte müssen diese zunächst aus dem Projekt ermittelt werden. Dafür muss eine Vollgenerierung durchgeführt werden, die alle referenzierten Medien in der richtigen Auflösung generiert. Außerdem erzeugt sie die in den Projekteinstellungen initialisierten XML-Kollektoren und füllt sie anhand der in den Vorlagen enthaltenen xmlCollector-Aufrufe.
Fügen Sie dem Auftrag daher zuerst eine Generierungsaktion hinzu und wählen Sie für diese einen beliebigen Namen.
In den Eigenschaften sind außerdem die folgenden Optionen zu wählen (vgl. Abbildung Aktion Content Preparation):
Vollgenerierung durchführen
Generierungsverzeichnis vorher leeren
Medien im Generierungsverzeichnis erzeugen
|
Der Einsatz des WebDAV-Moduls ist nur in Verbindung mit dem Standard-Url-Creator möglich.
Wählen Sie für die Pfaderzeugung daher zwingend den Eintrag |
Des Weiteren ist ein beliebiges Präfix für absolute Pfade zu definieren.
Dieses wird in der letzten Aktion WebDAV-Deployment benötigt.
Wechseln Sie anschließend auf die Registerkarte Erweitert und selektieren Sie die Vorlagensätze aller im Projekt vorhandenen Sprachen.
Alle an die Commerce Cloud übermittelten Daten werden von dieser in Form von XML-Dateien erwartet. Aus diesem Grund müssen die während der Vollgenerierung ermittelten Informationen aus den erzeugten XML-Kollektoren ausgelesen werden. Sie sollen stattdessen in eine jeweils zu erstellende XML-Datei geschrieben werden.
Fügen Sie dem Auftrag daher für jeden in den Projekteinstellungen initialisierten XML-Kollektor eine weitere Generierungsaktion hinzu und benennen Sie diese beliebig.
Selektieren Sie anschließend in den Eigenschaften die Option Teilgenerierung durchführen für folgende Startpunkte.
Ein Klick auf den Button öffnet einen separaten Dialog, der die Struktur- und die Medien-Verwaltung anzeigt.
Wählen Sie für jede Aktion jeweils eine der auf der XML-Vorlage basierenden Seitenreferenzen und bestätigen Sie die Auswahl mit .
Die Seitenreferenz wird daraufhin als Startknoten in den Eigenschaften der Generierungsaktion angezeigt (vgl. Abbildung Teilgenerierung).
Wechseln Sie anschließend auf die Registerkarte Erweitert und legen Sie über den Button die Variable dwre_xmlGeneration an.
Sie muss den Wert true erhalten.
|
Mit der Variablen und über die Auswahl des Startknotens kann sichergestellt werden, dass die selektierte Seitenreferenz erst zu diesem Zeitpunkt generiert wird. Somit liegen alle benötigten Informationen für die Erstellung der XML-Datei bereits vor und es können keine Lücken auftreten. Die Erzeugung der XML-Datei wird durch die im Projekt enthaltene XML-Vorlage gesteuert. |
Die mit den Teilgenerierungen erzeugten XML-Dateien müssen abschließend an die Commerce Cloud übermittelt werden. Die Publizierung erfolgt über ein Skript, das dem Auftrag zwingend als letzte Aktion hinzuzufügen ist und den folgenden Aufruf enthält:
Deployment-Skript.
#!executable-class com.espirit.ps.custom.deploy.WebDavDeployment
Öffnen Sie anschließend per Klick auf den Button den gleichnamigen Dialog und legen Sie die folgenden Parameter an (vgl. Abbildung Eigenschaften):
URL gibt den Host und den Pfad auf dem WebDAV-Server an.
Sie besitzt immer die folgende Struktur:https://<SUBDOMAIN INSTANCE>.demandware.net/on/demandware.servlet/webdav/Sites/Impex/…/<PREFIX>/<SITE ID>
|
Der Pfad entspricht dem Ort, an dem die jeweilige XML-Datei während des Imports erwartet wird.
Er muss auf ein bereits existierendes Verzeichnis verweisen. |
|
Der technische Benutzer unterliegt den durch die Commerce Cloud definierten Passwort-Bestimmungen. Diese erfordern eine vierteljährliche Änderung des Passworts. Der Wert des Parameters muss in jedem dieser Fälle zwingend angepasst werden. |
mediaurl festzulegen.
Die mediaurl besitzt immer die folgende Struktur:http://<SUBDOMAIN INSTANCE>.demandware.net/on/demandware.servlet/webdav/Sites/Libraries/<SITE ID>/default/<PREFIX>
srcprefixdir relativ zum Root-Knoten des Generierungsverzeichnisses angegeben werden.
Wird der Parameter nicht definiert oder für ihn kein Wert gespeichert, wird das gesamte Generierungsverzeichnis übertragen.
true oder false besitzt.
Der Wert true bewirkt, dass alle Dateien und Verzeichnisse unterhalb der angegebenen URL vor dem Start der Übertragung gelöscht werden.
Besitzt der Parameter den Wert false oder garkeinen Wert, bleiben alle bestehenden Dateien und Verzeichnisse unterhalb der angegebenen URL bestehen.
Neue Daten werden entweder hinzugefügt oder im Fall von bereits existierenden Daten überschrieben.
|
Das WebDav-Deployment darf nicht im Fehlerfall ausgeführt werden. |
Die Commerce Cloud bietet die Möglichkeit, Inhalte nur für spezielle Zielgruppen oder bestimmte Zeiträume anzeigen zu lassen. Soll eine solche Personalisierung durch die Redakteure in FirstSpirit definiert werden können, müssen einige Voraussetzungen geschaffen werden. Diese werden nachfolgend für die Eingrenzung der Inhalte auf Zielgruppen erläutert und anhand des mitgelieferten Beispielprojekts beschrieben.
Die Filterung der redaktionellen Inhalte erfolgt auf der Basis auswählbarer Zielgruppen, die Commerce Cloud-seitig definiert werden.
Die Commerce Cloud bietet jedoch keine Möglichkeit, diese Gruppen auszulesen und in FirstSpirit bereitzustellen.
Aus diesem Grund muss innerhalb des FirstSpirit-Projekts eine Datenquelle erstellt werden, in der dieselben Zielgruppen manuell anzulegen sind.
Jeder Datensatz muss dabei mindestens die aus der Commerce Cloud stammende ID sowie einen beliebig wählbaren Namen besitzen (vgl. Abbildung Zielgruppen in FirstSpirit).
Weitere Informationen zur Erstellung einer Datenquelle erhalten Sie in der FirstSpirit Online Dokumentation.
Die Bereitstellung der Zielgruppen für die Redakteure erfolgt im Formular einer Seite oder eines Absatzes. Grundsätzlich bestehen diesbezüglich keine Einschränkungen und die Darstellung kann beliebig umgesetzt werden. Es bietet sich jedoch die Verwendung einer der folgenden Eingabekomponenten an:
Innerhalb des mitgelieferten Beispielsprojekts werden die Zielgruppen über eine Combobox zur Verfügung gestellt:
Combobox.
<CMS_INPUT_COMBOBOX name="st_role"> <CMS_INCLUDE_OPTIONS type="database"> <LABELS> <LABEL lang="*">#item.name</LABEL> </LABELS> <TABLE>standard.roles</TABLE> </CMS_INCLUDE_OPTIONS> <LANGINFOS> <LANGINFO lang="*" label="Customer Group"/> </LANGINFOS> </CMS_INPUT_COMBOBOX>
Diese ist in den verwendeten Absatzvorlagen enthalten und referenziert die Datensätze der erstellten Datenquelle.
Über die Auswahl einer Zielgruppe wird ihr der redaktionelle Inhalt zugeordnet. Mit dem Deployment wird diese Zuordung zur Commerce Cloud übertragen und dort auf die tatsächliche Zielgruppe gemapped. Damit bleibt die Personalisierung auch im Live-Stand erhalten und wird dort angewandt.
Mit der Verwendung der Multi Perspective Preview wird den Redakteuren im ContentCreator eine Möglichkeit geboten, eine der Zielgruppen anzunehmen. Die Redakteure erhalten so eine spezifische Sicht auf die Webseite und können auf diesem Weg die von ihnen definierte Personalisierung der Inhalte überprüfen. Ohne diese Möglichkeit würde ihnen immer nur eine allgemeine Ansicht des Inhalts angezeigt und eine Überprüfung wäre nur im Live-Stand möglich.
Um eine der Gruppen anzunehmen, wird in FirstSpirit eine Seitenvorlage benötigt, die ebenfalls alle Zielgruppen für die Redakteure bereitstellt. Innerhalb des mitgelieferten Beispielprojekts wurde dafür auch an dieser Stelle eine Combobox verwendet. Weitere Anforderungen an die Seitenvorlage bestehen nicht.
MPP-Rollen.
<CMS_INPUT_COMBOBOX name="mpp_roles"> <CMS_INCLUDE_OPTIONS type="database"> <LABELS> <LABEL lang="*">#item.name</LABEL> </LABELS> <TABLE>standard.roles</TABLE> </CMS_INCLUDE_OPTIONS> <LANGINFOS> <LANGINFO lang="*" label="Customer Group"/> </LANGINFOS> </CMS_INPUT_COMBOBOX>
Nach der Erzeugung der Seitenvorlage muss die Multi Perspective Preview aktiviert werden.
Öffnen Sie dafür den ServerManager und wechseln Sie auf den Bereich → .
Selektieren Sie anschließend über den entsprechenden Button die erstellte Seitenvorlage als Vorschau-Parameter (vgl. Abbildung Auswahl der Vorschau-Parameter ).
Ein Klick auf den Button speichert die vorgenommenen Änderungen.
Wird im ContentCreator über die Multi Perspective Preview eine Zielgruppe selektiert, ist die Darstellung der Seite entsprechend anzupassen. Dafür muss jedoch zunächst die ausgewählte Gruppe ermittelt werden. Dies kann beispielsweise über die folgende JSP-Abfrage erfolgen:
Abfrage bezüglich der Auswahl einer Zielgruppe.
$CMS_IF(#global.is("WEBEDIT"))$
<% if (session.getAttribute("fs.preview.mpp_roles") != null) {
String role = session.getAttribute("fs.preview.mpp_roles").toString(); %>
[...]
<% } %>
$CMS_END_IF$
|
Diese Abfrage ist nur bis einschließlich FirstSpirit 5.1 einsetzbar.
Ab FirstSpirit 5.2 muss über die |
Die Abfrage stellt zunächst sicher, dass es sich bei der aktiven Umgebung um den ContentCreator handelt und greift nur dann. Anschließend ermittelt sie die selektierte Zielgruppe, wenn die Auswahl nicht leer ist. Eine Behandlung dieses Zustands und die damit verbundene Anpassung des dargestellten Inhalts muss stets projektspezifisch erfolgen.
Im mitgelieferten Beispielprojekt wird die Anzeige des Inhalts über CSS gesteuert. Dabei sind die spezifischen Inhalte initial ausgeblendet und werden sichtbar, sobald die zugehörige Zielgruppe selektiert wird.
Darstellung über CSS.
<style type="text/css"> .$CMS_VALUE(ps_mppCssPrefixRole)$ {display:none;} .$CMS_VALUE(ps_mppCssPrefixRole)$<%= role %> {display:block;}; </style>
Die gesamte Abfrage ist im Beispielprojekt innerhalb der Formatvorlage Preview Generation enthalten, die über einen $CMS_RENDER$-Aufruf in der verwendeten Seitenvorlage eingebunden ist.
Beid er Verwendung von Slots müssen die für die Personalisierung definierten Parameter in der Slot Configuration ergänzt werden.
Der nachfolgende Code-Ausschnitt zeigt beispielhaft, wie dies erfolgen kann.
Slot Configuration.
$CMS_SET(set_slotConfig)$ ❶ <slot-configuration slot-id="cat-banner" ❷ context="category" context-id="$CMS_VALUE(pt_dwre_previewPageId)$" ❸ configuration-id="$CMS_VALUE("fs_slot_configuration_" + #global.section.id)$" default="true" assigned-to-site="true"> <template>slots/content/categorybanner.isml</template> <enabled-flag>true</enabled-flag> <content> <content-assets> <content-asset content-id="$CMS_VALUE(set_xml_id)$"/> </content-assets> </content> $CMS_IF(!st_role.isEmpty)$ <customer-groups> <customer-group group-id="$CMS_VALUE(st_role.getValue().id)$"/> ❹ </customer-groups> $CMS_END_IF$ </slot-configuration> $CMS_END_SET$ $CMS_IF(#global.language==#global.project.masterLanguage)$ $CMS_SET(set_xml_lang,"x-default")$ $CMS_SET(void,ps_xmlCollectorContentSlot.addXml(null,set_slotConfig.toString(),null))$ ❺ $CMS_END_IF$
|
Es wird zunächst die Variable | |
|
Innerhalb dieses XMLs wird neben der entsprechenden aus der Commerce Cloud stammenden | |
|
Anschließend wird die ID der auswählten Zielgruppe abgefragt. Die Auswahl der Zielgruppe erfolgt durch die Redakteure über die zuvor erstellte Combobox. | |
|
Das XML muss abschließend dem passenden XML-Kollektor übergeben werden, der in den Projekteinstellungen initialisiert wird. An dieser Stelle und im Beispielprojekt handelt es sich dabei um den Kollektor |
Diese Konfiguration ist im Beispielprojekt innerhalb der Absatzvorlage Banner enthalten.
Die Content Integration API bietet eine alternative Möglichkeit personalisierten Inhalt anzuzeigen.
Die Content Integration API bietet eine zusätzliche Möglichkeit, Inhalte aus FirstSpirit in der Commerce Cloud darzustellen. Anders als beim bisher beschriebenen Verfahren werden hierbei Velocity Vorlagen anstelle von Slots genutzt.
Dadurch ändert sich die Rolle, die FirstSpirit bei der Gestaltung einer Seite einnimmt. Im slotbasierten Ansatz wird das Rahmenwerk einer Seite Commerce Cloud-seitig definiert und FirstSpirit ergänzt lediglich an festgelegten Stellen Inhalte. Auch einfache Änderungen am Rahmenwerk erfordern deshalb immer eine Anpassung der Commerce Cloud-Vorlage und der enthaltenen Slots, was durch Redakteure nicht geleistet werden kann. Dieses Problem ist noch gravierender, falls die Änderung nur einzelne Seiten betrifft.
Die Verwendung der Content Integration API versetzt FirstSpirit dagegen in die Lage, vollständige Seiten auszuliefern, wodurch Redakteuren mehr Freiraum bei der strukturellen Gestaltung einer Seite gegeben werden kann. Absätze können sie also in einem projekt- und seitenspezifischen Umfang selbstständig anordnen, ohne dass dafür Vorlagenänderungen vorzunehmen sind.
Des Weiteren können Entwickler die Fähigkeiten Velocitys ausnutzen, um Logik in Vorlagen zu implementieren. Zur Entwicklung eigener Funktionen steht ihnen dabei die Commerce Cloud Script API zur Verfügung. Die programmatischen Möglichkeiten in Vorlagen sind folglich sehr groß und können zum Beispiel genutzt werden, um personalisierten Inhalt in einer Seite darzustellen.
Eine parallele Nutzung des slotbasierten Ansatzes und der Content Integration API ist ohne Einschränkung möglich, weshalb für jede Seite bzw. Seitentyp der passende Ansatz gewählt werden kann.
Dieses Kapitel beschreibt einen Ansatz zur Nutzung der Content Integration API mit FirstSpirit. Neben den Inhalten, die weiterhin in Content Assets gespeichert werden, generiert und veröffentlicht FirstSpirit hierbei Velocity Seitenvorlagen. Die Darstellung einer Seite geschieht über einen speziellen JavaScript Controller, der Content Asset und Velocity Seitenvorlage verbindet.
Dieses Kapitel beschreibt die Commerce Cloud-seitige Erweiterung, die für die Integration notwendig ist. Dabei handelt es sich um einen JavaScript Controller, der eine spezielle Funktionalität umsetzen muss, darüber hinaus aber projektspezifisch erweitert werden kann.
Des Weiteren wird in diesem Kapitel auf das Thema Caching eingegangen, dessen richtige Konfiguration vor allem für personalisierte Inhalte relevant ist.
|
Für dieses Kapitel wird angenommen,
dass der JavaScript Controller in der Cartridge unter dem Pfad |
Der JavaScript Controller soll ein übergebenes Content Asset auslesen und mit Hilfe einer Velocity Seitenvorlage darstellen. Diese Aufgabe lässt sich in vier grundlegende Schritte unterteilen:
cid auslesen
Diese Schritte sowie ihre Implementierung werden im Folgenden beschrieben.
|
Der vollständige Quellcode des hier beschriebenen minimalen Controllers ist in Anhang A, JavaScript Controller zu finden. |
|
Die Implementierung des Controllers beschränkt sich bewusst auf seine Kernfunktionalität, um sie einfach und leicht verständlich zu halten. Für einen produktiven Einsatz sollte sie unter anderem um eine Validitätsprüfung der Parameter und eine solide Fehlerbehandlung erweitert werden. |
Der JavaScript Controller enthält eine öffentliche Methode Show, die als Einstiegspunkt zum Rendern von Content Assets dient
und die Klassen dw.template.Velocity und dw.content.ContentMgr aus der Commerce Cloud Script API verwendet.
Das Grundgerüst des Controllers sieht somit wie folgt aus:
"use strict"; var contentManager = require("dw/content/ContentMgr"); ❶ var velocity = require('dw/template/Velocity'); ❷ exports.Show = function() { ❸ // ... }; exports.Show.public = true; ❹
|
Einbinden der Klasse | |
|
Einbinden der Klasse | |
|
Definition der Methode | |
|
Öffentlichen Zugriff auf die Methode |
Zum Auslesen des Content Assets wird zunächst der HTTP-GET-Parameter cid ermittelt,
dessen Wert dann dem ContentMgr übergeben wird, um das Content Asset auszulesen.
Falls ein Redakteur eine neue Seite anlegt, ist der Commerce Cloud noch kein entsprechendes Content Asset bekannt.
Um in FirstSpirit trotzdem eine Vorschau für die neue Seite zu ermöglichen,
wird in diesem Fall ein temporäres Objekt anstelle des Content Assets verwendet,
das ein leeres Asset imitiert.
var contentAssetId = request.getHttpParameterMap().get("cid"); ❶ var contentAsset = contentManager.getContent(contentAssetId) ❷ || { custom: { body: "" }, template: "welcome_page.vs" }; ❸
|
Auslesen des HTTP-GET-Parameters | |
|
Abfrage des Content Assets | |
|
Definition eines leeren Dummy-Assets, falls kein Content Asset mit der übergebenen Id gefunden wurde |
Anschließend wird ein Objekt mit dem Namen global definiert.
Mit diesem Objekt wird der Velocity Engine eine spezialisierte API bereitgestellt,
deren Funktionen und Eigenschaften in der verarbeiteten Velocity Seitenvorlage nutzbar sind.
Struktur und Inhalt dieses Objektes müssen projekt- und seitenspezifisch definiert und implementiert werden.
Denkbar sind zum Beispiel Funktionen, die unter einem sprechenden Namen verschiedene Widgets einbinden.
var global = {
❶
};
|
Projekt- und seitenspezifische Eigenschaften und Funktionen |
Die Eigenschaft body speichert den Inhalt des Content Assets
und muss beim hier beschriebenen Ansatz immer in irgendeiner Form im global-Objekt vorhanden sein.
Da der Inhalt des Assets selbst Velocity Code enthalten kann,
wird dieser zunächst über die Velocity Engine interpretiert und das Ergebnis in body gespeichert.
Beim Rendern des Content Assets kann der Velocity Engine ein separates Parameter-Objekt zur Verfügung gestellt werden.
Genauso ist es aber möglich, global wieder zu verwenden.
function render(content, parameters) {
var writer = new dw.io.StringWriter();
velocity.render(content, parameters, writer)
return writer.toString();
}
// ...
global.body = render(contentAsset.custom.body, global);
Abschließend wird die am Content Asset hinterlegte Velocity Seitenvorlage gerendert und das Ergebnis dem Aufrufer angezeigt.
Als Parameter-Objekt wird das zuvor erstellte Objekt global übergeben.
velocity.renderTemplate(contentAsset.template, global);
Die Commerce Cloud bietet viele Möglichkeiten Seiten zu cachen und so schnelle Antwortzeiten zu gewährleisten. Falls eine Seite kunden- oder sessionabhängige Informationen enthält und das Caching nicht richtig konfiguriert ist, kann es jedoch schnell zu unerwarteten Ergebnissen kommen.
Aufbauend auf den Erläuterungen des Kapitels JavaScript Controller wird im Folgenden anhand eines konkreteren Beispiels ein Ansatz erläutert, der ein korrektes Ergebnis sicherstellt.
Anzuzeigen ist eine aus vier Blöcken bestehende Seite. Bei diesen Blöcken handelt es sich um
Diese Blöcke bieten unterschiedliches Potential gecacht zu werden.
Der Banner ist lediglich abhängig vom Geschlecht des Kunden. Das heißt, dass alle Kunden in zwei Gruppen unterteilt werden können: weibliche und männliche Kunden. Innerhalb einer Gruppe ist der Inhalt für alle Kunden identisch, wohingegen Kunden verschiedener Gruppen verschiedene Inhalte sehen. Aus diesem Grund kann der Inhalt für beide Gruppen getrennt und für einen längeren Zeitraum gecacht werden. Allerdings muss bei jedem Seitenaufruf das Geschlecht des Kunden ausgewertet werden, um den richtigen Cache anzusprechen.
Der Header enthält Informationen, die abhängig von jedem einzelnen Kunden sind, wie zum Beispiel seinen Namen. Für diese Komponente muss das Caching also pro Kunde erfolgen. Die Gültigkeit des Caches kann dabei kurz gehalten werden, da die kundenspezifischen Inhalte im Vergleich zu allgemeinen Inhalten seltener und für kürzere Zeit benötigt werden.
Der Footer wird nicht personalisiert und kann deshalb für alle Kunden und für einen langen Zeitraum gecacht werden.
Der Inhalt des Content Assets kann selbst Velocity Code enthalten, weshalb er getrennt betrachtet werden muss. Allerdings gelten für ihn die gleichen Überlegungen, weshalb auf ihn nicht weiter eingegangen wird.
Die einzelnen Komponenten stellen unterschiedliche Anforderungen an das Caching,
weshalb es sinnvoll ist, jede in einem separaten Widget zu kapseln,
sodass für jedes das Caching einzeln gesteuert werden kann.
Da das Commerce Cloud-Caching auf URLs basiert und einem Widget Parameter über seine Anfrage-URL übergeben werden,
kann das Caching der Widgets über Parameter gesteuert werden.
Für das Banner-Widget ist beispielsweise ein Parameter isFemale sinnvoll, der einen boolschen Wert enthält.
Es sind also zwei gültige URLs denkbar, was zu zwei Caches für das Widget führt: Einer für weibliche und einer für männliche Kunden.
Genauso kann für das Header-Widget ein Parameter id definiert werden, in dem die Id des Kunden abgelegt wird.
Dadurch wird der spezifische Inhalt für jeden Kunden einzeln vorgehalten.
Die einzelnen Widgets werden dann beim Rendern der initial aufgerufenen Seite über Remote Includes integriert. Das vollständig zusammengesetzte Ergebnis dieser Seite kann ebenfalls gecacht werden, wodurch die Einstellungen der einzelnen Widgets ausgehebelt werden würden und es doch zu unerwarteten Ergebnissen käme. Deshalb ist es wichtig, diese Antwort nicht zu cachen. Folglich wird die angeforderte Seite also bei jedem Aufruf neu zusammengebaut, die einzelnen Komponenten jedoch durch ihr individuelles Caching wiederverwendet.
Realisiert wird dies über den JavaScript Controller und das Parameter-Objekt global,
welches er der Velocity Engine bereitstellt.
Das global-Objekt enthält in diesem Beispiel die parameterlosen Funktionen include.banner(),
include.header() und include.footer(), die an den passenden Stellen in der Velocity Seitenvorlage aufgerufen werden.
Des Weiteren beinhaltet es wie bisher die Eigenschaft body,
die den Inhalt des Content Assets speichert.
Innerhalb der include-Funktionen werden die jeweiligen Widgets über passend parametrisierte Velocity.remoteInclude-Aufrufe in die Seite integriert.
Der initial aufgerufene JavaScript Controller, der das global-Objekt erzeugt und das Rendern der Velocity Seitenvorlage anstößt,
darf wie angesprochen nicht gecacht werden,
damit er bei jedem Seitenaufruf ausgeführt wird und die Caching-Einstellungen der einzelnen Widgets nicht umgangen werden.
Dies ist das Standard-Verhalten, weshalb kein zusätzlicher Code notwendig ist.
Das Zusammenspiel zwischen Velocity Seitenvorlage, Parameter-Objekt und Widgets ist in Abbildung Caching Beispiel dargestellt.
Dieses Kapitel beschreibt die FirstSpirit-seitigen Erweiterungen, die für die Integration notwendig sind.
Die verwendete Velocity Seitenvorlage wird in FirstSpirit gepflegt und an die Commerce Cloud übertragen. Dazu ist in FirstSpirit zunächst eine Seitenvorlage anzulegen, deren Ausgabekanal für dieses Beispiel folgenden Inhalt hat:
<!DOCTYPE html> <html> <body> <!-- CMS-PREVIEW-CONTENT-START --> ❶ $body ❷ <!-- CMS-PREVIEW-CONTENT-END --> ❸ </body> </html>
|
Diese HTML-Kommentare werden benötigt, um später die Vorschau in FirstSpirit zu generieren. | |
|
An dieser Stelle wird der Inhalt des Content Assets eingebunden. Der Parameter |
|
Die Ziel Extension der Seitenvorlage muss im Reiter |
Auf Basis dieser neuen Seitenvorlage muss anschließend jeweils genau eine Seite und eine Seitenreferenz angelegt werden. Dabei sollte zumindest die Seitenreferenz in einem separaten Ordner auf der obersten Ebene der Struktur platziert werden, um die spätere Übertragung der Velocity Seitenvorlage zur Commerce Cloud zu vereinfachen.
Die Velocity Seitenvorlage wird nach der Freigabe der in Kapitel Velocity Seitenvorlage erzeugten Objekte von FirstSpirit generiert. Zur Übertragung zur Commerce Cloud muss der in Kapitel Deployment-Auftrag beschriebene Auftrag um ein weiteres WebDAV-Deployment erweitert werden. Dies geschieht am einfachsten, indem eine Kopie der Aktion aus Kapitel WebDAV-Deployment erzeugt und angepasst wird. Folgende Parameter sind zu überarbeiten:
https://<SUBDOMAIN INSTANCE>.demandware.net/on/demandware.servlet/webdav/Sites/Dynamic/<SITE ID>
en/velocity_templates.
Alle sonstigen Parameter können übernommen werden.
Da dieser Ansatz zur Nutzung der Content Integration API weiterhin Content Assets erzeugt, gelten für Seitenvorlagen für redaktionelle Inhalte alle Überlegungen aus Kapitel Seitenvorlage. Es sind lediglich zwei spezifische Anpassungen vorzunehmen.
Zum einen muss das Attribut template am Content Asset gepflegt sein,
da dieses im JavaScript Controller herangezogen wird, um die richtige Velocity Seitenvorlage zu ermitteln.
|
Der JavaScript Controller kann natürlich so entwickelt werden, dass er eine Default-Velocity-Seitenvorlage auswählt, falls am Content Asset keine hinterlegt ist. |
Des Weiteren muss für alle neuen Seitenvorlagen ein neuer Page Type definiert werden,
damit die für die Vorschau generierte URL den richtigen JavaScript Controller-Aufruf enthält.
Konkret muss also die Variable pt_dwre_previewType auf einen neuen Wert gesetzt werden.
Für das Beispiel dieses Kapitels wird dafür content benutzt.
Die in der Auslieferung enthaltene Formatvorlage Create Preview URL muss um einen weiteren Fall erweitert werden,
damit die Vorschau für Seiten, die die Content Integration API nutzen, korrekt funktioniert.
Der verwendete Vergleichswert hängt vom neuen Page Type ab, der in der Seitenvorlage aus Kapitel Seitenvorlage für redaktionelle Inhalte verwendet wurde.
Entsprechend hängt die aufgerufene URL vom Namen des Controllers, der aufzurufenden Methode sowie der benötigten Parameter ab (siehe Kapitel JavaScript Controller).
In diesem Beispiel wäre der neue Eintrag in der Vorlage Create Preview URL also:
$CMS_CASE("content")$Content-Show?cid=$CMS_VALUE(pageId)$
Eingangs wurde bereits darauf hingewiesen, dass mit der Content Integration API Redakteuren mehr Möglichkeiten bei der Gestaltung einer Seite gegeben werden können. Visuelle Komponenten, die ein Redakteur auf einer Seite platzieren und anordnen können soll, werden Commerce Cloud-seitig am besten als Widget implementiert. Auf Seiten FirstSpirits bietet es sich dann an, für jedes Widget eine Absatzvorlage zu definieren.
Innerhalb des Ausgabekanals einer solchen Vorlage muss zwischen Vorschau und Nicht-Vorschau unterschieden werden.
Für die Vorschau wird die Anfrage-URL des Widgets bestimmt.
Diese URL wird dann dem Skript include_html übergeben, welches Teil der Auslieferung ist.
In diesem Skript wird die URL aufgerufen und das Ergebnis in die generierte Seite eingefügt.
|
Damit ein Widget so über das Internet abgerufen werden kann, muss der öffentliche Zugriff auf das Widget gestattet sein. |
Für die Generierung des Content Assets wird stattdessen lediglich ein Velocity-Aufruf erzeugt. Welche Funktion aufgerufen wird und welche Parameter sie erwartet, hängt vom Parameter-Objekt ab, welches im JavaScript Controller definiert und der Velocity Engine beim Rendern des Content Assets übergeben wird.
Ein generalisiertes Beispiel ist in Listing Ausgabekanal einer Absatzvorlage eines Widgets zu sehen. Zum Einbetten des Widgets wird eine allgemeine Funktion verwendet, die den Namen des Widgets und die benötigten Parameter entgegennimmt.
|
Beim Referenzieren von Widgets sollte Augenmerk auf deren Caching gelegt werden. |
Ausgabekanal einer Absatzvorlage eines Widgets.
$CMS_IF(#global.isPreview)$
<div $CMS_VALUE(editorId())$ >
$CMS_SET(set_includeURL, ps_dwProtocol + ps_dwInstance + ".demandware.net/on/demandware.store/")$
$CMS_SET(set_includeURL, set_includeURL + "Sites-" + ps_dwSiteId + "-Site/")$
$CMS_SET(set_includeURL, set_includeURL + #global.language.abbreviation + "/")$ ❶
$CMS_SET(set_includeURL, set_includeURL + <ACTION> + <PARAMETER>)$
$CMS_RENDER(script:"include_html", includeURL:set_includeURL.toString())$
</div>
$CMS_ELSE$
$include.widget("<ACTION>", <PARAMETER>)
$CMS_END_IF$
|
Als Sprache wird die Abkürzung der aktuell generierten FirstSpirit-Sprache verwendet. Bei Bedarf muss hier ein eigenes Mapping auf eine Commerce Cloud-Locale implementiert werden. |
Mit der Content Integration API kann Shop-Besuchern personalisierter Inhalt dargestellt werden, ohne dazu auf Slot Configurations zurückzugreifen.
Stattdessen kann die Personalisierung über Velocity in Kombination mit der Commerce Cloud Script API erfolgen. Abhängig von den konkreten Projektanforderungen können dabei verschiedene Ansätze und Implementierungen verfolgt werden.
Eine simple Umsetzung nutzt im Content Asset eine if-else-Verzweigung,
die verschiedene Personalisierungs-Fälle abbildet und so nur der passende Inhalt dargestellt wird.
Der entsprechende Abschnitt im body des Content Assets sieht dann wie folgt aus:
#if ($customer.isInGroup('Big Spenders'))
<!-- Content for Big Spenders -->
#elseif ($now.isBetween('2016-10-01', '2016-11-01'))
<!-- Content for all other customers during October 2016 -->
#else
<!-- Content in all other cases -->
#end
In diesem Beispiel wird Kunden der Gruppe Big Spenders spezieller Inhalt dargestellt.
Genauso wie allen anderen Kunden im Zeitraum vom 01.10.2016 zum 01.11.2016.
Abschließend wird der Inhalt für sonstige Kunden außerhalb dieses Zeitraumes definiert.
Die genutzten Funktionen $customer und $now werden im Parameter-Objekt definiert,
welches der Velocity Engine im JavaScript Controller übergeben wird (vgl. JavaScript Controller).
Ihre Implementierung nutzt die Commerce Cloud Script API.
|
Die Nutzung der Content Integration API hat keinen Einfluss darauf, wie die Personalisierung für die Vorschau in FirstSpirit umgesetzt wird. |
|
Die Implementierung des Controllers beschränkt sich bewusst auf seine Kernfunktionalität, um sie einfach und leicht verständlich zu halten. Für einen produktiven Einsatz sollte er z.B. um eine Validitätsprüfung der Parameter und eine solide Fehlerbehandlung erweitert werden. |
Vollständiger JavaScript Controller.
"use strict"; var contentManager = require("dw/content/ContentMgr"); var velocity = require('dw/template/Velocity'); function render(content, parameters) { var writer = new dw.io.StringWriter(); velocity.render(content, parameters, writer) return writer.toString(); } exports.Show = function() { var contentAssetId = request.getHttpParameterMap().get("cid"); var contentAsset = contentManager.getContent(contentAssetId) || { custom: { body: "" }, template: "welcome_page.vs" }; var global = { // ... }; global.body = render(contentAsset.custom.body, global); velocity.renderTemplate(contentAsset.template, global); }; exports.Show.public = true;
ContentConnect ist ein Produkt der e-Spirit AG, Dortmund, Germany.
Für die Verwendung des Modules gilt gegenüber dem Anwender nur die mit der e-Spirit AG vereinbarte Lizenz.